A frame buffer is a common component in many conventional graphics processing systems. A frame buffer may comprise one or more memory buffers (e.g., a z-buffer) that are used to contain at least one complete frame of data for communication to a video display device. As illustrated in FIG. 1, an exemplary computer system 100 comprises a processor 102 operable to execute software applications 104 and a graphics processing unit 108 operable to receive graphics information from the software applications 104 and to process video and graphics information and deliver it for display by a display device 112. As illustrated in FIG. 1, the processor 102 is operable to execute software applications 104 that interact with graphics drivers 106 and deliver video and graphics information to the graphics processing unit 108 for processing. An exemplary graphics processing unit 108 may comprise a frame buffer 110 operable to store graphics e.g., pixel data necessary for at least one complete frame of data to be displayed by the display device 112. The contents of the frame buffer 110 may also be read out by the graphics processing unit 108, processed, and updated with current graphics data during rendering.
As illustrated in FIG. 2, graphics information stored in a frame buffer memory 110 may be divided into tiles 202. Each tile 202 may comprise one or more display pixels 204. An exemplary tile may have a rectangular shape or a square shape. A tile 202 may comprise a variety of different pixel quantities (e.g., 12 pixels/tile and 64 pixels/tile). As illustrated in FIG. 2, an exemplary tile 202 may comprise 16 pixels 204 arranged into a 4×4 array. As also illustrated in FIG. 2, a tile 204 may contain a plurality of objects 208, 210 that cover one or more pixels 204 of the tile 202.
A tile 202 may be covered by any number of objects. An object is a generic term and may represent for example: triangles, layers, z-planes, or a collection of samples with a common property (e.g., color) that overlie pixels, etc. Rather than pixels 204, an exemplary tile 202 may also be referred to as comprising samples 206. An exemplary pixel 204 may comprise one or more samples 206. An exemplary pixel 204 may also comprise a multisample that is an average of all the color samples of the pixel 204.
Exemplary graphics data, such as distance or z-data, runs through a graphics pipeline in the graphics processing unit 108, where triangles may eventually be sorted by tiles 202. As discussed herein, the tiles 202 may be collections of pixels or any subset of the pixels to be displayed on the display 112. In one exemplary embodiment, data coming down the graphics pipeline (source data) may arrive in two different representations. A first representation comprises z-plane information that provides geometric descriptions of a particular plane for the associated z-data, described as Ax+By+C. The parameters A and B are the gradients of the z-plane in x and y respectively. The parameter C is the distance of the z-plane from the origin, e.g., the center of the tile. Thus, these parameters fully describe the orientation and placement of the z-plane in space. A second representation comprises individual z values for each sample or pixel, such that individual depth or distance values for each sample or pixel of a tile are specified directly. In one exemplary embodiment, z-planes are evaluated at sample locations. For non-antialiased or non-multisampled rendering, there is only one sample per pixel. When there is only a single sample for a pixel, a sample is equivalent to a pixel, otherwise, a pixel comprises a plurality of sample values.
In addition to the source data, there is also exemplary destination data, representing the geometry that has already been rendered to the frame buffer (e.g., a z-buffer). One or more compression algorithms may have been applied to this data, such that it can be either in a compressed or an uncompressed state, or it could be subdivided into tiles or other regions, and partially compressed in some regions and uncompressed in others. When z-data is stored in the z-buffer in an uncompressed representation, individual distance values for each sample are stored. When z-data is compressed for storage in the z-buffer, the z-data may be stored using z-plane representations, which as discussed herein comprise a geometric description (Ax+By+C) for each z-plane and a coverage mask for each z-plane.
A comparison may be made between the destination data that has already been rendered and the new source data. This new data may be used to update the z-data stored in the z-buffer. For an exemplary tile 202, destination data stored in the z-buffer may be read out and compared to source data to determine which fragments are visible at the tile 202 according to their associated distance data (a fragment may be considered a collection of samples with a common property (e.g., color) that overlie pixels, etc.). The z-values are compared to determine which fragments are visible. The results may then be written back into the z-buffer as updated result information. This updated result information is now updated destination data.
Exemplary z-data may arrive as one or more z-planes (the first representation discussed above), or as individual z-data for each sample or pixel (the second representation discussed above). When the z-data is represented with z-planes, the z-planes (that is, the z-plane information) may be stored in the z-buffer. Storing the z-data as z-planes allows for the compression of the z-data. In other words, rather than storing individual z-values for each sample, one or more z-planes (and their associated coverage masks) representing the z-values may be stored in the z-buffer instead. When z-data is represented by individual distance values for each sample (the second representation), there will not be any compression, as z-data for each sample will need to be stored in the z-buffer. Because graphic geometries are getting finer, individual z-planes are also covering an ever smaller number of screen pixels, which results in potentially greater numbers of z-planes for a given tile. Conventional z-data compression techniques (using z-plane representations) are only able to store a limited number of z-planes. When this limit is reached, the z-data must be stored uncompressed in the z-buffer.